The present invention relates to the processing of information. In particular, the invention relates to the representation of data on the screen of a computer or similar device.
Background art systems typically use three approaches for representation of data residing in a database on the screen of a computer or similar device: grids, forms and reports. In a simple example, if one wanted to query a database about families, one would have to pose the query in some way. For example, one might have a window into which could be typed a Standard Query Language (SQL) query, such as:                Select * from Dad, Kids where Dad.name = ‘Nick’ and Dad.id = Kids.parent;Activating this query would bring up a rectangular table containing all combinations of the rows in each table that fit the query where-condition.        
The results of such a query would typically be displayed in a grid as shown at 201 in FIG. 1. This grid is an area containing data records of the same type, with column header labels displayed at the top of the grid. FIG. 1 shows background art grid control 201 containing a representation on a display of the result of a join between the two tables, ‘Dad’ and ‘Kids,’ and a selection on the name of the parent, as shown in the SQL query presented above. One having ordinary skill in the art would know that a grid control has an outer frame 202. It may be possible to resize and move this frame around the screen. The contents of the grid control are a number of cells of various types arranged into a grid. The contents within the frame are usually scrollable up and down and side to side when the total data contents do not fit entirely within the bounds of the frame, but this aspect is not shown here. In software applications involving access to databases, it is common for the top cells of a grid to contain the names of the columns of the table in the database being queried. This is shown in top cells 203 through 206 which contain the column names qualified with their table name. Below this header row are the data cells, such as data cell 207.
Referring to FIG. 1, the result of the query on two relational tables ‘Dad’ and ‘Kids’ is shown. The ‘Dad’ table has two columns: ‘name’ which contains the text of a father's name, and ‘id’ which is the primary key for the record and has no other function. The ‘Kids’ table has two columns: ‘name’ which contains the text of a child's name and ‘parent’ which acts as a foreign key to relate a particular child to his or her parent. Thus, the ‘Dad’ table is a master table, and the ‘Kids’ table is a detail table. The two are related by a primary key/foreign key pair. The data shown in FIG. 1 are used herein to illustrate many points about relational data. One having ordinary skill in the art would understand that the query result contains data from two ‘Dad’ records whose primary keys are 1 and 2. These two records are joined with the ‘Kids’ records whose ‘parent’ fields refer to one of the two ‘Dad’ records.
It is common in background art database software applications for the header row to be operative to activate manipulation of the data displayed below it. For example, pointing at a cell in the header with cursor 208 may enable one to manipulate the data by dragging and dropping with the mouse. Furthermore, it is often the case that columns can be resized or moved. In the case illustrated in FIG. 1, the column ‘Kids.name’ has been selected and the mouse has been right-clicked. This has the effect of displaying on the screen a menu of action options that are possible for the selected cell.
It is also common in the background art for data cells within grid controls to present menus of action options. Those having ordinary skill in the art will know that, depending on the cell that has been chosen, the action options vary. For example, in the case of data cell 207, it makes no sense to sort the contents of a single cell. However, for selected cell 205, the cell is a column header that represents the whole column. Menu of options 209 is specific to that column. In this case, sorting is a sensible option. If the user selects a ‘Sort’ option, all of the rows will be sorted so that the contents of each row is unchanged but the rows are sorted in the order specified for the selected column. In background art database interfaces, it is usual for the column header cells to have more options available to them than other kinds of cells. No background art reference discloses an invention that permits the selection of a data cell to offer the action of joining the cell to further unfetched (unretrieved) data within the database.
In background art user interfaces, often there is also a cell that does not contain data to the left of each row of data. A cell like this, such as cell 210, may also have options available to it when selected, such as hiding the row, or increasing its depth to show several lines of text. No background art reference discloses an invention that increases the functionality of this cell to the left of the record 210 or allows it to occur in other parts of the grid.
In recent years, editing of elements of data presented in grids has been supported in background art grid controls. In this case, the changed data are either saved as a group or various means are used to co-ordinate changing of the value on the screen with updating the underlying data in the database.
In the example given above, the five entries for a parent of name ‘Nick’ represent two parents. It will also be noticed that the ‘Dad.id’ column 204 and ‘Kids.parent’ column 206 hold essentially a form of meta-data. These meta-data join the real data together. The Dad.id does not tell the user anything about the Dad. Both of these problems, repeated data and meta-data are features of relational databases. All database systems use meta-data, but the relational system treats it as if it were real-world data.
For parts of software applications that typically manipulate one record in a master table and several in detail/child tables of the current record, it is common in the background art to use a forms approach, but recently, background art hierarchical grid controls have been developed. These allow a master-detail relationship to be displayed in a grid control. Examples are MSHFlexGrid from Microsoft Corp, Redmond, Wash., and UltraWinGrid from Infragistics Inc of Cranbury, N.J. Referring again to FIG. 2, background art hierarchical grid 211 is displayed. Grid 211 is displaying the same data as grid 201. The values in cells 213 and 214 replace the first three rows of ‘Dad.name’ column 204 and ‘Dad.id’ column 204, in background art grid 201. These two values constitute a master record, which is related to three detail records 216, 217 and 218. The detail records only appear if first-detailed records expansion node 212 for the master record is expanded. In the case of the second master record, second detailed records expansion node 219 is contracted (indicated by a ‘+’ sign), so there are no tree lines 215, and the detail records are not displayed. Nodes 212 and 219 can be expanded or contracted independently, and when contracted the master rows move closer to occupy the vacated space. Existing art hierarchical grids are typically linked to hierarchical datasets, such as those provided by ADO from Microsoft. For datasets in which a master record has two different detail record sets, existing art hierarchical grids are not capable of expanding and contracting different detail record sets for the same master record independently. However, existing art hierarchical grids solve the problem of repetition of data from the master table.
Forms have an important role to play in limiting users' access to subsets of the total data in the database, and to guide users through data input processes. In the relational database model, forms are usually used to present data that does not fall nicely into a tabular output. The fact that the same parent has more than one child is represented by having different areas of the form containing single items and lists. However, it would be advantageous to be able to replace some forms applications with a grid control of the present invention accessing a relational database via a standard interface of the present invention. As the grid control and relational database interface are generalized for any relational database schema, no programming effort would be required.
The present invention can handle many different data models, but this disclosure concentrates on object and relational data models. In the object model, a data record is called an object, and is identified by a unique object identifier (OID). This is like having an extra column in the equivalent relational record, but the OID is meta-data that cannot be modified by the user, and is usually not displayed. The object is usually of a type or class, which replaces the table of the relational model. In this disclosure, objects are referred to as being of a certain type. Types have a name and a list of attributes. The attributes are roughly equivalent to columns. The attributes have attribute types such as number, character string, binary large object (BLOB), in the same way as columns have data types.
The value of the attribute within a given object is called a data element throughout this section of the disclosure, although elsewhere the value is sometimes also called an attribute. Attributes can be multi-valued, which means the value of the attribute in a given object can be an array or list of data elements, whereas in the relational model the value must be single-valued. In a list, the order is not important, whereas in an array the position of the element in the list is important. The OID value of one object can be stored in a data element of another object, so the second object can refer to the first object. This is described in U.S. Pat. No. 5,615,367 and is a common practice in background art databases.
Some background art databases require, that for a given reference attribute, the data element must always point at an object of the same type. Less strict systems do not impose this limitation. The model used in this disclosure is the latter, but does not rule out the former.
FIG. 3 shows some of the object data that is be used in examples throughout this document. It shows three objects of type ‘family’, first ‘family’ object 501, second ‘family’ object 502 and third ‘family’ object 503, and one of type ‘car’, ‘car’ object 518. In the data model for object data throughout this disclosure, it is assumed that an object is retrieved by supplying an object identifier (OID). For objects 501, 502 and 503, the OID's are shown at 504, 505 and 506 respectively. Objects of type ‘family’ have four attributes: ‘Dad’, ‘Kids’, ‘Cars’ and ‘Homes’. Considering first ‘family’ object 501, ‘Dad’ attribute 507 is single-valued and has the value ‘Nick’ shown at 508. ‘Kids’ attribute 511 is multi-valued and contains the values ‘Fabio’ at first data element 512, ‘Patrick’ at second data element 513, and ‘Lucia’ at third data element 514. One ordinarily skilled in the art will see that if one disregards ‘Cars’ attribute 515, and ‘Homes’ attribute 516, the two objects 501 and 502 represent the same data as that extracted from a relational database and displayed in the grid of FIG. 2. The OID's 504 and 505 are the equivalent of the primary keys of the ‘Dad’ table. The ability to store multi-valued attributes means that two tables can be replaced by one object type, and the foreign key column ‘Kids.parent’ column 206 is not needed in the object data model.
‘Cars’ attribute 515, and ‘Homes’ attribute 516 are multi-valued attributes. They store references to other objects. The value stored at (reference) value 517 in the ‘Cars’ attribute is the OID of an object of type ‘Car’. This referenced object is shown at ‘car’ object 518. Although the value for object 501 has only one element, the ‘Cars’ attribute is multi-valued as will be seen later. ‘Homes’ attribute 516 is also multi-valued, and for first ‘family’ object 501 has two elements with values 5 and 6, which are the OID's of two objects not shown here.
In the object data model presented here, OID's are similar to primary keys in the relational model, and references are similar to foreign keys. The relational system does not support multi-valued fields.
The object data shown in this disclosure is ideally suited to the visual elements used in the present invention. The unit for grouping data on the screen is called a record in this disclosure. The object data used in the disclosure can be represented with one record per object. Although the attributes in these objects may be multi-valued, the elements are always atomic. This means that they are things like numbers, strings of text or single blocks of binary data that have no internal structure (as far as the database is concerned). There are object and semi-structured data models (as well as object-relational databases), which allow elements in single-valued or multi-valued attributes to consist of a series of sub-attributes. In some cases an attribute can itself contain a type. In these cases a single record on-screen is not capable of representing a single object or record of the underlying data model. The present invention maintains a common visual interface in these cases by treating this kind of data as containing lists of references, even though these references are to data within the object, rather than outside it. This will be covered in more depth later.
The background art of the present invention is characterized by U.S. Pat. Nos. 5,495,567; 5,546,526; 5,615,367; 5,657,460; 5,692,175; 5,729,730; 5,745,891; 5,835,683; 5,848,424; 5,873,079; 5,884,304; 5,884,306; 5,918,225; 5,940,818; 5,966,704; 5,995,984; 6,009,432; 6,014,138; 6,016,497; 6,081,801; 6,085,202; 6,108,651; the disclosures of which are incorporated by reference as if fully set forth herein.
Iizawa et al. in U.S. Pat. No. 5,495,567 disclose an automatic interface layout generator for database systems. This invention is limited in that it focuses on automatic layout generation.
Li et al. in U.S. Pat. No. 5,546,526 disclose a system for reconfiguration of a database by interactive manipulation of icons. This invention is limited in that it teaches re-grouping of columns in databases.
Bennett et al. in U.S. Pat. No. 5,615,367 disclose a system for automatic linking of tables for improved relational database modeling. This invention is limited in that it addresses only forms and not grids.
Egan et al. in U.S. Pat. No. 5,657,460 disclose a system for storing and displaying data. This invention is limited in that requires display of a visual representation of the object whose data are being displayed.
Davies et al. in U.S. Pat. No. 5,692,175 disclose a system for accessing and analyzing data. The invention is limited in that it applies only to large-scale entities such as databases, filters and report generators and does not concern individual data records.
Wlaschin et al. in U.S. Pat. No. 5,729,730 disclose an information storage and retrieval system. The invention is limited in that it does not teach visual representation of data.
Minakuchi et al. in U.S. Pat. No. 5,745,891 disclose a data search apparatus. The invention is limited in that it concerns highlighting portions of data that are to be displayed at certain locations on a display screen.
Corella et al. in U.S. Pat. No. 5,835,683 disclose a system and method for authoring an expert system. The invention is limited in that it calls for all displayed data to be contained within a single interaction cell that is not visible at runtime.
Scheinkman et al. in U.S. Pat. No. 5,848,424 disclose a data navigator interface with navigation as a function of draggable elements and drop targets. This invention is limited in that it requires dragging and dropping actions on the part of the user.
Davis, III et al. in U.S. Pat. No. 5,873,079 disclose a filtered index apparatus and method. This invention is limited in that does not teach visual display of data.
Davis, III et al. in U.S. Pat. No. 5,884,304 disclose an alternative key index query apparatus. This invention is limited in that does not teach visual display of data.
Bliss et al. in U.S. Pat. No. 5,884,306 disclose a system and method for directly manipulating fields for grouping items on a display. This invention is limited in that it teaches only the grouping of existing data in categories.
White et al. in U.S. Pat. No. 5,918,225 disclose a SQL-based database system with an improved indexing methodology. This invention is limited in that it teaches storing data vertically instead of horizontally.
Malloy et al. in U.S. Pat. No. 5,940,818 disclose attribute-based access for multi-dimensional databases. This invention is limited in that it concerns n-dimensional data.
Furegati et al. in U.S. Pat. No. 5,966,704 disclose storage systems based on the concept of storage plane organization. This invention is limited in that it teaches organizing data in storage roughly in order of data entry.
Lau et al. in U.S. Pat. No. 5,995,984 disclose an apparatus and method for zoom-in entry of a element in a table. This invention is limited in that it teaches switching between a forms-based representation and a grid-based representation of data on a display.
Tarin in U.S. Pat. No. 6,009,432 discloses a value-instance-connectivity database. This invention is limited in that it concerns only database storage techniques.
Cain et al. in U.S. Pat. No. 6,014,138 disclose a visual programming development system. This invention is limited in that it teaches the storage of OID's in columns.
Suver in U.S. Pat. No. 6,016,497 discloses a method and system for storing and accessing embedded information in object-relational databases. This invention is limited in that it teaches only access and storage of data.
Cochrane et al. in U.S. Pat. No. 6,081,801 disclose shared nothing parallel execution of procedural constructs in SQL. This invention is limited in that it applies only to a parallel-processing environment.
Rao et al. in U.S. Pat. No. 6,085,202 disclose a method and system for producing a table image having focus and context regions. This invention is limited in that it concerns n-dimensional data.
Guha in U.S. Pat. No. 6,108,651 discloses heuristic co-identification of objects across heterogeneous information sources. This invention is limited in that teaches joining tables in different databases using metadata.
In summary, no single reference or combination of references teaches the novel aspects of the present invention. There still exists a need for improved functionality in an devices and methods for representing and managing data.